Miggybyte 4/Miggybyte 4.adf/DOCS/MB_7.txt

Text File | 1996-02-14 | 12KB | 237 lines

     ===== Dr. Hepler on Hombre [he was the one in charge of it]=====


I have seen a lot of discussion over the past months on the pros and cons
of  various RISC processors and the future of the Amiga.  Since it was my
responsibility  to make some of these decisions in the past, and now that
Escom  has  announced their decision, I thought that some of you may find
it  interesting  to hear some of my views as I remember them and get some
insight  into  how  decisions  like  this  are made...  or at least how I
approached  things.   From  what  I  have seen on the net, many folks out
there have no clue as to how things like this are really done :-)

Remember  that  much  of this happened well over two years ago...  and my
memory  is not as good as it perhaps should be...  Take all of this to be
my  opinion....   you  may disagree with whatever you like...  First, you
have  to  put  this into context.  In order to make a decision like this,
one  has  to have a strategic plan for the future.  This plan then drives
the decision process.  As such I had some ground rules to start with:

a.  Only one chip set would be developed...  We only had enough R&D money
for  one...  so it had to address the low-end (game console, set-top-box)
to  high end (work-station, A4000 style machine)...  The requirements for
low-end systems are so different than those of high-end systems that this
is quite difficult...

b.  It had to be capable of supporting Windows-NT sometime in the future.
Amiga-DOS  would  be  ported (at least the micro-kernel for game systems,
set-top-boxes)...   the  rest later (for low-end systems)....  but it was
felt (at the time) that NT would be the emerging OS...  and compatibility
would be necessary for market acceptance outside of the traditional Amiga
market.   Having  support  for  a  "more  main stream" OS would have made
getting  main  stream  applications  ported to the machine *much* easier.
This  ground  rule  meant  that  we  wanted  a platform which had some NT
porting  activity  at  least started...  It also had some implications on
the type of memory management needed.  No flames please.

c.  I knew that we could not support a *complete* line of products within
Commodore with our resources...

But  I  felt  that  we could not have a product line which did not have a
link  of some kind to more powerful machines like those used in business.
Most  people  like  to  have  something  at  home  which  is  in some way
compatible  with  what  they  use at work.  I wanted to select a platform
which  gave Hombre users a growth path for the future.  We wanted to have
a  strategic  partnership  with  a  company  which  had a *complementary*
product line...  and perhaps cross-promote, etc.

d.   I  wanted to be able to include the integer core of the processor on
one  of  the  Hombre  chips.   We  also  wanted  to  be able to add a few
instructions to aid in graphics setup, etc.

e.  I was targeting a 0.6 micron, 3-level metal CMOS process.

Of  course  cost was a major concern.  I have seen many people on the net
discuss  RISC  chips  *without* considering the cost as it applies to the
overall system.  In order to build a system like the A1200, hit the price
point  that  we  wanted, and make a profit, the CPU chip, custom graphics
chips,  etc,  have  to cost about $20 (total!!).  Many folks forget about
all  the  other  costs  involved  in  producing  a  product.   This alone
eliminates  many  of  the  candidates that some have proposed and cheered
for...   Our  cost  objective  for  the Hombre chip set was a little more
liberal than this since I was integrating more onto the chips...  but the
cost  target was not much more!!  Certainly not some of the prices I have
seen  bantered  about some of the groups here.  Remember, we wanted to be
able to put this into a game console or set-top box.  You can't spend 1/3
of  the  retail price of the product on the CPU chip!!!  I looked at many
(almost all the commercially available) architectures (my favorite from a
purely  computer  architect  (my  primary  training)  viewpoint  was  the
MC88100)...   and  narrowed  down  to three:  MIPS, PowerPC, and PA-RISC.
Lew E.  and I talked to all the companies involved:


MIPS:

MIPS  was  interesting  because their parent company is Silicon Graphics.
Wouldn't  it  be  nice  to  have a strategic partnership with the premier
high-end   graphics   company!!!    We  could  have  built  the  low  end
"home-version" of their machine, made great games, etc.  Lew and I talked
with one of the founders and he asked lots of questions, etc., but didn't
sound  too  interested...  The 4200 series MIPS chips where too expensive
and  they didn't seem too interested in making any changes for us...  The
R3000  series  was  in  the  right  cost  area,  but  was  not viable for
Windows/NT.   As  I  said  above,  we  felt at that time that it would be
important for this chip set to be able to support NT in the future.

We  dropped  them  from  the  list  and found out shortly thereafter that
SGI/MIPS had signed an agreement with Nintendo for their next generation.
It  was  obvious then that they knew when they had talked to us that they
were  in  discussions with Nintendo...  It must have been interesting for
them...

By the way, at that point, we were 9 months to a year ahead of them...


PowerPC:

Motorola  talked  to  us about PowerPC (IBM may have come in too, I don't
remember)...   We  had  a  good  working  relationship with Motorola as a
vendor.   I  had  earlier done a study to integrate AA type functionality
onto a die with an MC680x0 core.

I had a number of problems with the PowerPC:

a.   An  early  version  of the instruction set documents (received under
NDA)  caused  me  to  have  a  real  concern about using this part in our
product line.  Lew E.  agreed.  I can't really discuss this any further.

b.   They  were  unwilling  to  do a full-custom version for us (with our
graphics enhancements) and their time-table for core-versions was too far
out.

c.   There  was  no  good  strategic relationship from a systems point of
view.    It   seemed   unreasonable   to   approach   Apple:   they  were
competitors...   their  line was not complementary.  The same was true of
IBM, and Motorola did not have a strong systems presence.

d.   A  small,  embedded version of PowerPC (the one that we could afford
for  the  low end...  (which was being developed for use in automobiles))
did  not  have a memory management option...  something required for both
Windows/NT and set-top-boxes.

e.   The  core  version that they did promise would have required that we
add  our  logic  as  standard  cells.   A standard cell implementation of
Hombre  would  have  been  far  too  large - and therefore expensive.  We
intended  to  do  a  custom  layout of the datapaths involved and merging
these datapaths with their logic was viewed as a problem...

f.   I  felt  the  instruction set had some problems...  for example, the
only  way to get information between integer registers and floating point
registers was through memory!


PA-RISC:

HP presented the PA-RISC.  We had a rather good working relationship with
HP.  They had fab'd the LISA chips and had done all the foundary work for
the AAA project.

The PA-RISC:

a.   It  had  one  of  the  most  powerful  RISC  instruction  sets I had
evaluated.   It  created  very  dense code (for a RISC) - and the dynamic
cycle  count  was  very  good.   It  also  had an instruction (SFU) which
allowed customization without interfering with compatibility...

I  had  defined some instructions which would aid in the 3D graphics that
had been planned for Hombre.

b.   Other PA-RISC partners had already shown that a low-cost version was
feasible.

c.   HP  had  a  totally  complementary  product  line  -  their  low end
workstations were more powerful than our high end Amigas.

d.   HP  seemed  interested  in  the  current  Amiga chipset for use in a
set-top-box  and  seemed  interested  in  the  Hombre  chipset for a next
generation  set-top-box.  This made good business sense and allowed us to
propose a rather nice agreement...  By the way, Commodore died before the
agreement could be signed.

e.   HP  was  willing  to  license  Commodore to design and build our own
version  of a core for use in Hombre.  I had designed the integer core of
the CPU and showed them (HP) simulations of it (to prove our competence).
(This  was  done  with  only  the  instruction  set reference manual - no
proprietary  information  or  design  was received from HP.) I'm not sure
that  the license was really necessary...  I had in effect created my own
implmentation  of  a  published instruction set...  Many others have done
this  with  other  instruction  sets without a license...  but having the
license  would  have  been  nice  and  their  cooperation would have been
useful.

f.   While  the  HP  chips  were  not available on the open market, other
partners  of theirs did have chips that could be put into systems.  These
other  processors  would  have been used as the external processor on the
larger systems I proposed.

The  architecture that was proposed by me (and approved by Lew) was a two
chip  set.   One  chip was a video buffer for the most part...  the other
chip held the internal cpu, blitter, and other goodies, etc.  By the way,
the internal datapath was a full 64 bits.  There were two bonding options
to  get  a  lower  costing  32 bit memory interface for game-consoles and
set-top  boxes,  and  a  slightly more expensive 64 bit option for higher
ended  systems  (VLSI  packaging  costs  can be significant for large pin
counts).   The wider memory was not really necessary for the very low end
systems  which  only had to produce NTSC or PAL level video, and was less
expensive...   Low  end  products  used  the  internal processor as *the*
processor.    Higher  end  systems  used  the  internal  processor  as  a
peripheral/graphics  processor.  While it made a lot of sense to have the
external  processor  be  a  PA-RISC  processor,  there  was  nothing that
required it.

The  architecture  also  made  use  of  the  PCI  bus.  Again, on low end
systems, the PCI held peripherals for use by the internal processor.  For
higher  end  systems  this  was also true.  But the PCI bus could also be
turned  around...  this allowed the chip set to be used *as a peripheral*
to  any PCI based system.  This was intended to allow this chip set to be
used  as  a  peripheral  to  PCs.   Also,  this  was the "link" to the HP
workstations.  It was hoped that this chip set could be configured onto a
PCI  card  for  incorporation  into  HP workstations...  This would allow
software which ran on our systems run on HP workstations...

I  had  written  a  simulation of the CPU, enhanced blitter/renderer, and
memory  interface  in  C  to  test  instruction  sequences  and rendering
performance.   (The  simulation  even  had  a  Tcl/Tk  GUI!).  I had also
modelled  many  of  the  blocks  in  M (a behavioral simulation/synthesis
language - similar in function to VHDL or Verilog).  Some of the datapath
had  started  transistor  level design...  Then things fell apart and the
couple  of  people I had just gotten assigned to work on this either quit
to  take  other jobs or were laid-off...  Remember before you flame me...
Most  of  this  happened  over  two  years ago.  Had we remained solvent,
gotten  the resources that had been promised and remained on our original
schedule, we would have had first silicon at the beginning of 1995!

I believe that given the strategy, ground rules, information at the time,
etc., I made the correct decision.  I don't know what strategy Escom has,
what  their ground rules were or how they made their decision, so I can't
comment on their selection...

I  hope this insight has been interesting and educational....  :-) Again,
all  of  the  above  is  my  opinion...  not to be taken as the policy or
beliefs of my employers, etc.

Dr. Edward L. Hepler     Former:
President,                Director of VLSI and System Architecture VLSI

Concepts, Inc.       Architect of Hombre, Designer of Andrea (AAA)
  VLSI Architecture,      Commodore
   Design, CAD

Adjuct  Prof.   ECE  Department,  Villanova  University ECE-8445 Graduate
level Advanced Computer Architecture ECE-8460 Graduate level Introduction
to VLSI Design [e-mail]

END
---